The Industry group known as the Open Mobile Alliance (OMA) has developed a Push to Talk over Cellular (PoC) specification aimed at enabling the provision of services over standard mobile wireless communication networks which resemble walkie-talkie services, i.e., at the push of a button, a subscriber can be connected almost instantly to one or more other subscribers. PoC is currently defined in the documents published by the Open Mobile Alliance, including PoC specifications 1.0 and 2.0.
PoC is based on the Session Initiation Protocol (SIP) specified in RFC3261 and the extensions developed by Internet Engineering Task Force (IETF). PoC systems are typically implemented on GSM/GPRS/3G networks and make use of the IP Multimedia Subsystem (IMS) standardised by the 3rd Generation Partnership Project to facilitate the introduction of advanced data services and, in particular, of real-time multimedia services into cellular networks. PoC Servers are located within the IMS or are attached thereto, and implement the functionality for setting up and controlling PoC sessions. PoC data comprises “bursts” carried over a packet network using Real-time Transport Protocol (as defined in RFC 2326).
The PoC infrastructure includes PoC Clients and PoC Servers. The PoC Client resides in a mobile terminal and is used to access the PoC service. A PoC Server acts either as the Controlling PoC Function (typically where the PoC Server is within the IMS network of the initiating party) or a Participating PoC Function (typically where the PoC Server is within the IMS network of a called party) or both. The determination of the PoC Server role takes place during PoC session establishment and is dependent upon the type of PoC session. Once the PoC Server roles have been determined they remain fixed for the duration of the session.
The PoC Server providing the Controlling PoC Function provides centralised PoC session handling which includes floor-control, Media distribution, policy enforcement for participation in PoC group sessions, and the PoC session participant information. Floor control involves granting the floor to one PoC client for a defined time period or until that client releases the floor, and thereafter allowing another client to take the floor. PoC floor control uses either a Talk Burst Control Protocol (TBCP) for PoC version 1.0 or Media Burst Control Protocol (MBCP) for PoC version 2.0. A PoC Server providing a Participating PoC Function provides PoC session handling which includes policy enforcement for incoming PoC sessions and relays Talk Burst Control and Media Burst Control messages between the PoC Client and the PoC Server performing the Controlling PoC Function.
FIG. 1 illustrates in extremely simplified terms the infrastructure that facilitates a PoC session between a pair of wireless terminals identified as UE-A 1 and UE-B 2. UE-A 1 and UE-B 2 include PoC Client A 3 and PoC Client B 4 respectively for supporting the PoC service. The terminals 1,2 are attached to respective radio access networks, RAN-A 5 and RAN-B 6, which in turn are connected to a packet-switched core network 7 including an IP backbone. SIP signalling is routed through the IMS 8, which includes SIP Application Servers acting as PoC Servers. The UEs are registered with respective PoC Servers, namely PoC Server A 9 and PoC Server B 10, although it is possible that both UEs are registered with the same PoC server. A PoC session can provide user voice and data communication between two users (one-to-one), or between a group of users in a group session (one-to-many).
Typically, when a user wants to communicate using a PoC service, the user presses the Push to Talk (PTT) button on their UE and then waits until a confirmation tone (beep) acknowledges that they can start to talk. The time between the user pressing the PTT button and the confirmation is defined in OMA PoC Specifications as KPI1.
Measurements have indicated that when implementing current OMA PoC specifications, KPI1 can be between 2.6 and 3.6 seconds. In some circumstances this time may be acceptable to the user. For example, for a PoC group session the PoC user initiating the session may not expect all members of the group to be instantly available. Furthermore, in some circumstances a PoC user may initiate or join a PoC Group session at the start of the working day and therefore, if the session takes a number of seconds to establish, this may not be a significant delay to such a user. However, when a user wants to communicate with only one other user, the user will expect to be able to establish communication almost instantaneously, i.e. as with a walkie-talkie, without such a delay. Therefore, it is desirable that this time, KPI1, is minimised as far as possible.
KPI1 can be reduced if the invited PoC Client can be configured to Automatic Answer Mode and that the PoC Server serving the invited PoC Client is configured to send an “Unconfirmed Indication” for that PoC Client. Automatic Answer Mode is a PoC Client mode of operation in which the PoC Client accepts a PoC session establishment request without manual intervention from the user; and any media is played immediately upon receipt. If a PoC Server is aware that a PoC Client it is serving is currently in Automatic Answer mode, then that PoC Server can be configured to send an answer on behalf of that PoC Client. This provides an Unconfirmed Indication back towards an inviting PoC Client to transmit media prior to receiving a final response from the invited PoC Client. The PoC Server serving the inviting PoC Client can then send a SIP 200 OK message and a MBCP Media Burst Granted message before the invited PoC Client has accepted the invitation. The inviting PoC Client will then give the user the confirmation tone (beep) acknowledging that they can start to talk. However, this mechanism requires that the PoC Server serving the inviting PoC Client buffer any media sent by the inviting PoC Client until the invited PoC Client has automatically responded by accepting the invitation. Only once the invited PoC Client has accepted the invitation can the media be sent towards the invited PoC Client. Whilst these settings can serve to provide an improved experience to PoC users it is still desirable to further minimise KPI1.